The Industry group know as the Open Mobile Alliance has developed a Push to talk Over Cellular (PoC) specification aimed at enabling the provision of services over standard mobile wireless communication networks which resemble walkie-talkie services, i.e. at the push of a button a subscriber can be instantly connected to one or more other subscribers. PoC is currently defined in the documents published by the Open Mobile Alliance: “Push to talk over Cellular (PoC)—Architecture”, Candidate Version 1.0—17, Mar. 2005, and “OMA PoC Control Plane”, Candidate Version 1.0—17, Mar. 2005. According to the PoC standards, voice data comprises talk “bursts” carried over a packet network, whilst the signalling used to establish and control PoC sessions comprises Session Initiation Protocol (SIP) signalling, also carried over the packet network. PoC relies upon the IP Multimedia Subsystem (IMS) infrastructure provided within the networks of mobile operators. PoC is a specific implementation of the general push-to-talk (PTT) services.
FIG. 1 illustrates in very basic terms the PoC infrastructure which facilitates a PoC session between a pair of wireless terminals (SIP clients) identified as UE-A and UE-B. The UEs are attached to respective radio access networks (RAN-A and RAN-B), which in turn are connected to a packet-switched core network including an IP backbone. SIP signalling is routed through the IMS which includes SIP application servers acting as PoC servers. The UEs are registered with respective PoC servers (although it is possible that both UEs are registered with the same PoC server).
The basic concept underlying PoC is the desire to allow one user to be almost instantaneously connected to another user, so that a user just has to press a call button and begin talking, with his or her voice being played out immediately on the other user's terminal. However, it was appreciated at a very early stage in the development of push-to-talk services that this may not always be desireable, at least from the point of view of the called party. Provision was therefore made for the playing of a ringing alert at the called terminal, in much the same way as is provided for with conventional telephone calls (push-to-talk services would still establish the session extremely quickly, much more quickly than conventional telephone calls can be established), with users being given the option to select either the auto-answer mode or the manual (ringing) answer mode.
According to the latest versions of the PoC standards, it is possible for a user (UserB) to register with his local PoC server, a “white” list of other user identities (UserA) for which the user wishes to apply the auto-answer mode. In the event that a PoC session is requested by one of the users on the white list, this is recognised by UserB's local PoC server, and that PoC server includes an auto-answer flag in the SIP INVITE message that is forwarded to UserB. UserB's terminal detects the flag, and automatically returns the SIP 200OK (answer) message. The session is established. If the calling user is not on the white list (or no white list has been defined), a manual flag is included in the SIP INVITE forwarded to UserB's terminal. This is detected by the terminal, and a ringing alert played. The SIP 200OK is not sent by the terminal to its local PoC server until the user answers. IETF draft “A Session Initiation Protocol (SIP) Event Package and Data Format for various settings in support for the Push-to-talk Over Cellular (PoC) service”, Miguel-Angel Garcia-Martin, draft-garcia-sipping-poc-isb-am-01, describes a method for notifying the local PoC server of the answer mode applicable to users on the white list. A user switches between the manual and auto-answer modes by signalling the desired mode to the PoC server using the SIP PUBLISH message as defined in the PoC standards.
This signalling process, including auto-answer mode setting and session establishment, is illustrated in FIG. 2. Signalling flows in the user plane (e.g. the exchange of Talk Burst Control Protocol messages) is not shown in the Figure. The steps illustrated in the Figure are as follows:                1. The PoC Client B configures automatic mode in the network by means of a PUBLISH request.        2. The PoC Server B acknowledges the automatic answer mode setting by means of a 200 “OK” response and stores the ‘auto’ setting.        
When the PoC User A presses the PoC button, the steps are as follows:                3. The PoC Client A decides to invite PoC User B to a PoC Session and sends an INVITE request to the PoC Server A.        4. The PoC Server A sends the INVITE request to the PoC Server B in the PoC User B Home Network.        5. The PoC Server B authorizes the PoC User A and selects the configured answer mode and sends a 183 “Session progress” response to the PoC Server A.        6. The PoC Server A sends a 200 OK response to the user A and the PoC User A receives an indication that he can start to speak.        7. The PoC Server B sends an INVITE request to the PoC Client B. The INVITE request includes the request for automatic answer mode.        8. The Client B accepts the invitation without prompting the PoC User B.        9. The PoC Server B forwards the 200 OK to the PoC Server A.        
The PoC standards define a mechanism for allowing a caller to override a manual answer mode setting specified by a called user. This involves the inclusion of a “MAO” parameter in the SIP INVITE message sent by the calling user to initiate the PoC session. Upon receipt of an INVITE containing the MAO parameter at the called party's terminal, that terminal automatically determines whether manual override is allowed for the calling user. If so, then the 200OK answer is automatically returned to the local PoC server, and the INVITE forwarded to the called user including the MAO parameter. If not, a ringing alert is played, and the answer message only sent out if and when the called user answers.